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APPEAL BRIEF 

Sir: 

Applicant respectfully appeals from the second office action mailed February 17, 2004. 

I. REAL PARTY IN INTEREST 
The real party in interest is the assignee Intel Corporation. 

IL RELATED APPEALS AND INTERFERENCES 
The issues are virtually identical to those already decided in Appeal No. 2002-0336 on 
the same application. 

III. STATUS OF THE CLAIMS 
Claims 1-26 are rejected for the second time. 
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IV. STATUS OF AMENDMENTS 
All other amendments have been entered. 

V. SUMMARY OF THE INVENTION 

Referring to Figure 1, a video distribution system 10 may be implemented in a variety of 
different video distribution environments including cable, television broadcast, or satellite as 
examples. The video provider 14, which may be a cable provider or a satellite system provider 
as examples, transmits video, as indicated at 16, to a plurality of receivers 12 which may be 
processor based television receivers. The processor based television receivers may, for example, 
be so called set-top computer systems which use a television receiver as a display. 

Instead of transmitting the video at a set or predetermined time corresponding to the time 
the video will be viewed, the video may be continually or semi-continuously streamed to all of 
the receivers in an encrypted form. Alternatively the video may simply be transmitted in 
advance and stored on a plurality of receivers. The individual receivers 12 may not be capable 
(without additional information) of displaying the transmitted video information. Thus, to the 
extent possible given the bandwidth of the system, video may be transmitted to the receiver 12 
and stored thereon, for example in a memory 22, for viewing at a later time. 

When a user desires to view particular video information, such as a movie, at any time, 
the user may simply request the decryption information, for example, from the video provider 
14. In a two-way transmission scheme the request for decryption information may be 
transmitted over the same transport that conveyed the video. Alternatively, a separate medium or 
channel may be used. In addition, the decryption information may be requested from a source 
different from the video provider 14, in one embodiment of the invention. See specification page 
3, line 2 through page 4, line 10. 
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The decryption information may then be transmitted with unrelated video information 16, 
in one example, to the receiver 12. For example, under control by the controller 15, the 
decryption information may be provided together with information about the intended recipient. 
Equipped with the decryption key for a particular video such as a movie, the receiver 12 can 
decrypt the video and allow the viewer to view the video on demand. 

Where each of the receivers 12 includes a unique identifier and the decryption 
information is coded for the requesting receiver, only the receiver whose identifier matches an 
identifier transmitted with the decryption key is able to decode the decryption key for the 
requested video. In addition, when the receiver requests the decryption information, the receiver 
may not only be provided the decryption information, but appropriate billing provisions may be 
implemented as well. 

Requests for the decryption information may be provided through a telephone network 20 
as one example. As another example, the request may be made over an electronic network, such 
as the Internet using electronic mail. Thus, in effect a back channel may be used to request the 
decryption information from the video provider or other source in one embodiment. The video 
provider (or other source) then may provide not only the decryption information, but in one 
embodiment of the invention, the information needed to access the receiver's memory for the 
selected video information may also be provided. See specification page 4, line 1 1 through page 
5, line 13. 

Referring now to Figure 2, software, in accordance with one embodiment, may be stored 
on the receiver 12 for implementing a video on demand system. The software 26 may begin by 
receiving and storing the encrypted video as indicated in block 28. In one embodiment, this may 
be done at particular times when volume in the transmission channel is low or the transmission 
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may be done continuously or semi-continuously so as to store a library of video files on the 
receiver 12. 

Upon request for video, as indicated in diamond 30, the receiver 12 requests a decryption 
key as indicated in block 32. This request maybe carried over aback channel, in one 
embodiment of the invention, through a network 20 such as the Internet or a telephone network. 
Next, the video, stored in an encrypted form on the receiver 12, is retrieved as indicated in block 
34. The video may then be automatically decrypted as indicated in block 36, and the display of 
the video may begin as indicated in block 38. 

Generally, it may be desirable to transmit a decryption key for sections or portions of a 
given video. Thus, to view the entire video, the receiver must receive one or more video 
decryption keys, each of which may be used to decrypt a portion (less than all) of the video 
information. The advantage of this technique is that a pirate must obtain a number of video 
decryption keys in order to decrypt the entire video. This makes it harder to pirate the decryption 
keys, decreasing the likelihood of theft of services. For example, a new decryption key may be 
needed for each minute of video. Therefore, it may be desirable to transmit a new decryption 
key every minute, once an initial request for decryption information has been made. See 
specification page 5, line 15 through page 7, line 10. 

If the user wishes to pause the ongoing video transmission (diamond 40), a signal may be 
sent, for example, over a back channel to the video provider 14 requesting a pause authorization 
(block 42). The video provider may respond by providing an acknowledgement number (block 
44). When the user wishes to resume the video transmission, the user may simply press a 
"resume" key and provide the acknowledgement number. The video provider then knows when 
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the particular receiver paused and provides the appropriate keys to allow the user to continue to 
view the rest of the video that was already requested, and presumably, billed. 

Turning now to Figure 3, an example of a system that may be used as a receiver 12 is 
illustrated. The receiver 12 may include a processor 65 coupled to an accelerated graphics port 
(AGP) chipset 66. The chipset 66 may be coupled to system memory 68 and the accelerated 
graphics port bus 70. The bus 70 in turn may be coupled to a graphics accelerator 72, also 
coupled to a video or television receiver 73. 

The chipset 66 may also be coupled to a bus 74 that receives a TV tuner/capture card 76. 
The card 76 may be coupled to a television antenna 78 which may also be a satellite antenna or a 
cable connection as additional examples. A connection to a network 90, such as a modem 
connection to the Internet or a network controller connection to a computer network may also be 
provided. 

The bus 74 is coupled to a bridge 80 which in turn is coupled to a hard disk drive 82. The 
hard disk drive 82 may store the software 26 and 46. The software 100 may be script transmitted 
from the transmitter 14 to assist in locating stored video information. See specification page 7, 
line 1 1 through page 8, line 4. 

Claim 1 inter alia calls for a controller to receive a request to pause the play of video and 
to automatically request a code to enable video play to be resumed at a later time. 

Claim 4 calls for a controller that receives a request for a code to enable the play of video 
to be paused and to be resumed at a later time and in response said controller automatically 
provides said code. 
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Claim 21 , dependent on claim 4, calls for a controller that transmits an acknowledgement 
number to a receiver in response to a request for a code to enable the play of video to be paused 
and to be resumed at a later time. 

Claim 10 calls for automatically requesting a code to enable video to be played at a later 

time. 

Claim 22 dependent on claim 10, calls for receiving an acknowledgement number and 
using the acknowledgement number to resume the play of video. 

Claim 14 calls for automatically requesting a code to enable the play to be resumed at a 
later time in response to a request to pause the play of video. 

Claim 24, dependent on claim 14, calls for enabling the user to press a button to resume 
the play of the video and in response to the operation of the button, automatically transmitting 
the code to enable resumed play of the video. 

The variety of different claimed elements in the above-recited claims demonstrates that 
there are a number of different ways to enable the play of video to be paused and restarted, for 
example without additional charge. 

VI. ISSUES 

A. Is Claim 1 Obvious Over Dan in View of Saward? 

B. Is Claim 4 Obvious Over Dan in View of Saward? 

VII. GROUPING OF THE CLAIMS 
For brevity on appeal, claims 1- 3 and 10-26 may be grouped, and claims 4-9 may be 
grouped. 
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VIH. ARGUMENT 

A. Is Claim 1 Obvious Over Dan in View of Saward? 

Claim 1 inter alia calls for a controller to receive "a request to pause the play of said 

video and automatically request a code to enable video play to be resinned at a later time". As 

explained in the Board's prior decision in this case: 

. . .the instant claims do not merely require a 'pause' 
feature. They require a specific way to restart the program at a 
later time after the pause. In particular, each of the claims on 
appeal requires a controller to request a 'code' to enable video play 
at a later time. 

Board Decision on Appeal No. 2002-0336 at page 4. 

The rejection of claim 1 starts off on page 4 with what the Examiner calls "an implicit 
assumption" that "it would have been obvious to one of ordinary skill in the art to provide 
measures to ensure restricted access to the video since Dan's system is an on demand system 
(i.e., available to paying clients only)." Of course, this premise is entirely irrelevant to the 
claimed invention. Moreover, it is statutorily insufficient to simply assume what is obvious. 

From this so-called implicit assumption, the Examiner concludes, again without any 
support, that "it would accordingly have been obvious to one of ordinary skill in the art to use 
any suitable method for discouraging accessibility to non-paying customers, such as encrypting 
(or scrambling) of videos, which is a very well known technique and, as shown by Saward, who, 
in a system similar to that of Dan, downloads recordable videos in a subscription-based video 
system (noting Figure 3 or 5)." See Paper No. 2, page 4. Again, the points are totally 
unsupported, totally irrelevant, and totally impermissible since they simply conclude what is 
obvious based on nothing in the references. 

'*5 
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Carrying the unsupported reasoning further, the Examiner then concludes from the 
previous two implicit assumptions that: 

In view of the fact that decrypting (descrambling) would 
have been obvious to incorporate in the system of Dan as taught by 
Saward, the system of Dan, as modified by Saward would require 
the decryption stage to be activated upon initiation of play, pause, 
and/or the resume codes used by Dan so managed by an inherent 
internal controller, thereby providing unscrambled and, therefore, 
presentable videos. 

Paper No. 2, page 4. 

Again, all of this is unsupported conjecture, completely improper since it is not based in 
any way on anything in the references. Of course, this is the exact same kind of reasoning that 
the Board addressed once before. There, the Board noted that "while the Examiner does not 
contend that Russo teaches such a 'code,' the Examiner does contend that it would have been 
'obvious to consider such a feature as a pause function, whereby the controller 150 would 
recognize this command by an inherent code , as a separate command from a resume or play 
command. . . ' Board Decision at page 4. 

Now, the Examiner again simply contends that the code is inherent. However, the Board 
noted that "the mere fact that a thing MAY result from a given set of circumstances is not 
sufficient to establish inherency." See Board Decision at page 4. The Examiner was specifically 
told that "the Examiner must provide a basis in fact and/or technical reasoning to reasonably 
support the determination that the allegedly inherent characteristics necessary flows from the 
teaching of the prior art." See Board Decision at page 4. Again, the Examiner has simply 
refused to provide any support for the rejection and, again, simply insists that somehow the 
feature is inherent. The use of the code in the claimed fashion is no more inherent here than it 
was in Russo. As in the case of the previous appeal, the Examiner, again, fails to substantiate 
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any alleged inherency. There is absolutely no reason to believe that a code must be read to 

enable play at a later time. 

In connection with the rejection of claim 14, the Examiner does contend that "when a 

pause request is prompted, the video is subsequently resumed automatically according to a 

resume request code sent to the head end (e.g., column 2, lines 46-49) as indicated in the flow 

chart in Fig. 5." See Rejection dated February 17, 2004 at page 2 under paragraph 2. The cited 

lines of Dan are set forth below to illustrate their total inapplicability to the present rejection: 

The priority request 1 10b is high if the request is for 
resuming a movie after a pause and normal if the request is for 
starting a movie. 

Plainly, this language has nothing to do with the claimed code. It merely has to do with 
the request. The request for a resume is a given a higher priority than a request to initially start 
play. But this has nothing to do with the controller to automatically request a code "to enable 
video play to be resumed at a later time." There is no code to enable play to be requested at a 
later time in Dan, just like there was no code in Russo, which was the subject of the previous 
appeal. 

Since the rejection is essentially the same rejection which the Board has already once 
reversed, the rejection should be reversed again. 
B. Is Claim 4 Obvious Over Dan in View of Saward? 

Claim 4 calls for a controller that receives a request for a code to enable the play of video 
to be paused and to be resumed at a later time and in response the controller automatically 
provides the code. 

Again, there is no reason why the reference necessarily would receive a request for a 
code and in response provide a code and moreover there is no reason that the code would be 
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provided automatically as a matter of absolute necessity. Therefore the rejection of claim 4 



should be reversed. 



CONCLUSION 



Since the rejections of the claims are baseless, they should be reversed. 



Respectfully submitted, 



Date: May 24. 2004 




Tinwfhy N. Trop, Reg. No. 28,994 
TROP, PRUNER & HU, P.C. 
8554 Katy Freeway, Suite 100 
Houston, TX 77024 
713/468-8880 [Ph] 
713/468-8883 [Fax] 



APPENDIX OF CLAIMS 



The claims on appeal are: 

1 . A receiver for receiving video information from a video transmitter comprising: 
a storage medium for storing video information received by a receiver; 

a decryption engine to decrypt stored video information; and 
a controller to control the storage medium and the decryption engine and request 
decryption information for the engine, said controller to control the play of video, to receive a 
request to pause the play of said video and to automatically request a code to enable video play 
to be resumed at a later time. 

2. The receiver of claim 1 wherein said controller includes a processor. 

3. The receiver of claim 1 wherein said engine is adopted to decrypt stored video 
upon receipt of a request to view stored video. 

4. A video transmission system comprising: 

a video transmitter that transmits video to a plurality of receivers for display at a 

later time; and 

a controller that transmits decryption information to said receivers to enable video 
upon request, said controller receives a request for a code to enable the play of video to be 
paused and to be resumed at a later time, and in response said controller automatically provides 
said code. 
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5. The system of claim 4 wherein said controller also is adapted to transmit an 
identifier which identifies a particular receiver to receive said decryption information. 

6. The system of claim 5 wherein said controller is part of said transmitter. 

7. The system of claim 4 wherein said video transmitter transmits video over a cable 

system. 

8. The system of claim 4 wherein said video transmitter transmits video over a 
satellite system. 

9. The system of claim 4 wherein said transmitter also transmits information to assist 
in locating particular video files transmitted by said transmitter to said receivers. 

10. A method comprising: 

storing encrypted video in a receiver; 
requesting a decryption key for said stored video; 
playing said video; 

receiving a request to pause said play of video; and 

automatically requesting a code to enable said video to be played at a later time. 

1 1 . The method of claim 10 including receiving the encrypted video from one source 
and receiving the decryption key from a second source. 
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12. The method of claim 10 including receiving the video and said decryption key 
from the same source. 

13. The method of claim 10 including receiving an identifier to identify a particular 
receiver to receive said key. 

14. A video distribution method comprising: 
storing video for selection by the recipient; 

upon request by the recipient, allowing the recipient to select for viewing a stored 

video; 

playing said video; and 

in response to a request to pause the play of said video, automatically requesting a 
code to enable play to be resumed at a later time. 

15. The method of claim 14 including providing a graphical user interface which 
displays the video information which is available for selection by the user. 

16. An article comprising a medium for storing instructions that cause a processor 
based system to: 

store video for selection by the recipient; 

upon request by a recipient, allow the recipient to select, for viewing, video 
previously stored; 

play said video; and 
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in response to a request to pause the play of said video, automatically request a 
code to enable play to be resumed at a later time. 

17. An article comprising a medium for storing instructions that cause a processor 
based system to: 

store encrypted video to a receiver; 

request a decryption key, for said stored video; 

play said video; 

receive a request to pause said play of video; and 

automatically request a code to enable said video to be played at a later time. 

18. The article of claim 17 including instructions that cause a processor based system 
to receive the encrypted video from one source and receive the decryption key from a second 
source. 

19. The article of claim 17 including instructions that cause a processor based system 
to receive the video and said decryption key from the same source. 

20. The article of claim 17 including instructions that cause a processor based system 
to receive an identifier to identify a particular receiver to receive said key. 
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21. The system of claim 4 wherein said controller transmits an acknowledgement 
number to a receiver in response to a request for a code to enable the play of video to be paused 
and to be resumed at a later time. 

22. The method of claim 10 further including receiving an acknowledgement number 
and using said acknowledgement number to resume the play of video. 

23. The method of claim 22 wherein using said acknowledgement number includes 
using said acknowledgement number to resume the play of video without an additional charge. 

24. The method of claim 14 further including enabling the user to press a button to 
resume the play of said video and in response to the operation of said button, automatically 
transmitting the code to enable resumed play of said video. 

25. The method of claim 24 further including receiving a key to enable decryption of 
the video. 

26. The method of claim 25 including resuming the play of video from the point 
where the video play was paused. 
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